A flash memory device is an electrically rewritable nonvolatile digital memory device that does not require a power source to retain its memory contents. A typical flash memory device stores charge on a floating gate to represent a first logic state in the binary state system, while the lack of stored charge represents a second logic state in the binary state system. Additionally, the typical flash memory device is capable of performing a write operation, a read operation, and an erase operation.
Within the flash memory industry, several small form-factor flash memory module standards have evolved to meet the memory demands of portable compact electronic products and to meet the demand for an easily removable compact storage medium. Each of these small form-factor flash memory module standards share the following features: a compact structure and a rugged design. One such standard is the Solid State Floppy Disk Card (SSFDC) standard, a vendor-independent standard crafted by the SSFDC Forum. A flash memory device complying with the SSFDC standard functions with SSFDC products manufactured by any SSFDC vendor. The SSFDC standard has gained wide support and acceptance since its inception because of its simple structure, high portability, and interchangeability. The SSFDC standard has the distinction of being the lightest and thinnest of the currently available flash memory module standards. With a dimension of 45.times.37.times.0.76 mm, a SSFDC flash memory device is about half the size and the same thickness as a credit card.
Compared with currently available memory module formats, which use a semiconductor memory assembled on board, the SSFDC standard possesses a much simpler structure. A SSFDC flash memory device has an embedded NAND-type flash memory chip, but does not include a controller or any other substantive support logic circuitry. This simplified design allows the manufacture of a less costly memory device as compared to other types of memory module standards.
The NAND-type structure alludes to the serial arrangement of the memory cells in the SSFDC flash memory. By contrast, the NOR-type structure has the memory cells arranged in parallel. An advantage of the NAND-type structure is faster sequential accessing than the NOR-type structure. In addition, the NAND-type structure supports faster write and erase operations and permits fabrication of higher density memory chips or smaller and less-expensive chips of the same density.
Since the SSFDC flash memory device does not have an integrated controller, the controller can be implemented in numerous embodiments. The controller can be designed directly in a host computer system--as hardware or firmware--, an adapter or as a software-only solution on the host computer system. Resembling a floppy disk drive in which one disk drive functions with numerous floppy disks from a variety of vendors, one SSFDC controller from any SSFDC vendor can be used with any SSFDC flash memory device from a variety of SSFDC vendors.
The SSFDC flash memory device is optimally suited for use in portable devices requiring internal data storage and in low cost consumer products that process data including digital cameras, personal digital assistants, electronic musical instruments, voice recorders faxes, smart cellular phones, pagers, and other portable information-related products. Moreover, the SSFDC flash memory device can be used in equipment requiring removable memory for portability, version upgrades, or memory upgrades for software applications. Besides adding portability to products, the SSFDC flash memory device facilitates the reduction in size of electronic products.
The potential for data corruption in large digital memories poses problems for mission critical computer operations. Since such errors are likely to occur in large digital memories, most modern digital memories incorporate some sort of data reliability procedure to detect and possibly correct errors in the data bits. The SSFDC standard implements a data reliability procedure known as Hamming Code, a type of error correcting code (ECC).
When data bits in a digital memory are moved or stored, there is always a possibility that a mistake can be made, that is, a logic HIGH state interpreted as a logic LOW state or a logic LOW state taken to be a logic HIGH state. This can be caused by media defects, electronic noise, component failures, poor connections, deterioration due to age, environmental perturbations, and other factors. The mistakenly interpreted data bit represents a corrupted data bit--a data bit error. This data bit error could be soft (transient) or hard (permanent). Since this data bit error is a natural consequence of the type of technology employed in digital memory design, the digital memory must compensate for this data bit error by utilizing appropriate logic such as an error correcting code (ECC).
An ECC allows data bits being read or transmitted to be checked for errors and, when necessary, correct the errors "on the fly". It is even possible to detect and restore erased data bits with a particular ECC. The ECC differs from parity-checking in that errors are not only detected but are also corrected--within certain limitations. The power of the ECC is determined by the number and types of errors the ECC is capable of detecting and correcting within the particular data bits being processed by the ECC. A high power ECC can detect and correct many more types of errors and a greater number of errors than a low power ECC. A Hamming Code is an example of a low power ECC, one capable of detecting all single data bit errors and double data bit errors, but correcting only the single data bit errors. A double data bit error indicates two distinct data bits contain errors. The ECC is needed to ensure the accuracy and integrity of data bits as speed and density of digital memories increase--which is usually accompanied by an increase in data bit error rates. In general, the ECC increases the reliability of any computing, telecommunication, and digital memory system without adding much cost. Additionally, the ECC can be integrated within the digital memory device or implemented outside the digital memory device. The fundamental features of the ECC are (1) a module for detecting and correcting errors and (2) extra data bits added by the ECC module to the units of data bits being sent to the digital memory for storage. These extra data bits cannot be utilized by an ECC other than the type of ECC that originally generated the extra data bits.
The ECC can either be implemented in hardware or software. Under most circumstances, errors must be detected and corrected "on the fly", meaning at the same rate as data bits are being read or transmitted. Typically, only a hardware-implemented ECC can provide the performance level for "on the fly" detection and correction at high data transmission rates.
Generally, the ECC performs the error detection and correction on units of data bits. The ECC adds extra data bits to each unit of data bits. These extra data bits are data reliability bits generated by the ECC in response to each unit of data bits. The data reliability bits, when combined with the unit of data bits, form a certain structure. If that structure is altered by errors, the changes can be detected and corrected--within certain limitations.
The basic concept of an ECC can be understood by analogizing with English words. A combination of letters of the English alphabet may or may not form a legitimate English word. The dictionary of the English language provides only the legitimate English words. Errors that occur when transmitting or storing English words can be detected by determining if the received word is in the dictionary. If it is not, errors can be corrected by determining which legitimate English word approximately resembles the received word. The ECC works in a similar fashion.
In practice, when a unit of data bits is stored in the digital memory, data reliability bits that describe the unit of data bits are calculated by the ECC and stored along with the unit of data bits. When the unit of data bits is requested for reading, data reliability bits for the about-to-be read unit of data bits are again calculated by the ECC. She newly generated data reliability bits are compared with the data reliability bits generated when the unit of data bits was stored. If the data reliability bits match, the unit of data bits is considered free of errors and sent to its destination. If the data reliability bits do not match, the missing or erroneous data bits are determined by the ECC and then supplied or corrected.
As mentioned earlier, the SSFDC standard employs an ECC known as Hamming Code. The data reliability bits for the Hamming Code are stored in the SSFDC flash memory device, but the actual Hamming Code module, which performs the error detection and correction, resides outside the SSFDC flash memory device--usually in the SSFDC controller. The Hamming Code cannot be changed to a different ECC by the vendor/manufacturer since the SSFDC standard is a vendor-independent standard for which a variety of SSFDC products have been designed. These SSFDC products are configured to operate only with the data reliability bits for the Hamming Code--not just any ECC--since the data reliability bits are meaningful only to the Hamming Code.
Inside the SSFDC flash memory device, the flash memory cells are divided into groups called blocks. Each block is further divided into units called sectors. The SSFDC standard requires each sector to be defined as denoted in FIG. 1. Each sector 100 must be a length of five hundred twenty-eight bytes. The five hundred twenty-eight bytes are parcelled as follows: five hundred twelve bytes to USER DATA 10, four bytes to SCRATCH DATA 20, one byte to DATA STATUS 30, one byte to BLOCK STATUS 40, two bytes to BLOCK ADDRESS 50, three bytes to ECC1 60, two bytes to BLOCK ADDRESS 70, and three bytes to ECC2 80.
USER DATA 10 is further divided into two hundred fifty-six bytes for USER DATA1 12 and two hundred fifty-six bytes for USER DATA2 14. Data bits sent to the SSFDC flash memory device for storage are stored in USER DATA1 12 and USER DATA2 14.
SCRATCH DATA 20 can be utilized by the vendor/manufacturer tor storing bits of vendor-specific information. Without SCRATCH DATA 20, the SSFDC flash memory device could still function properly as a storage device.
DATA STATUS 30 holds bits of information concerning the operability of USER DATA 10. The SSFDC standard specifies several possible patterns of bits within DATA STATUS 30 that are appropriate for indicating specific conditions of USER DATA 10. Under normal operating conditions, DATA STATUS 30 is set to FFh.
BLOCK STATUS 40 holds bits of information concerning the operability of the block of which the sector 100 is a part. The SSFDC standard specifies several possible patterns of bits within BLOCK STATUS 40 that are appropriate for indicating specific conditions of the block of which the sector 100 is a part. The specific conditions include: defective block and good block. Under normal operating conditions, BLOCK STATUS 40 is set to FFh.
BLOCK ADDRESS 50 holds bits indicating the block address of USER DATA 10.
ECC1 60 stores the data reliability bits which the Hamming Code needs in order to perform error detection and correction on the data bits in USER DATA1 12. These data reliability bits would be useless to an ECC other than the Hamming Code.
BLOCK ADDRESS 70 holds bits indicating the block address of USER DATA 10.
ECC2 80 stores the data reliability bits which the Hamming Code needs in order to perform error detection and correction on the data bits in USER DATA2 14. These data reliability bits would be useless to an ECC other than the Hamming Code.
For an illustration of how the Hamming Code interacts with the SSFDC flash memory device refer to FIG. 2 and FIG. 3. Focusing on FIG. 2, a unit of data bits 210 to be programmed into the SSFDC flash memory device 200 is first processed by the Hamming Code 250. From the Hamming Code 250, the unit of data bits 230 is sent to the SSFDC flash memory device 200 for storing. The data reliability bits 220 generated by the Hamming Code for the unit of data bits 210 is stored with the unit of data bits 230.
Focusing on FIG. 3, a unit of data bits 310 read from the SSFDC flash memory device 300 is first processed by the Hamming Code 350. The data reliability bits 320 previously generated by the Hamming Code 350 are also transmitted to the Hamming Code 350. Within the Hamming Code 350, the unit of data bits 310 is checked for errors and corrected if any errors are detected--refer to the earlier discussion of the ECC for an explanation of how the ECC, such as the Hamming Code, accomplishes the error detection and correction. From the Hamming Code 350, the unit of data bits 360--now checked and corrected--proceeds to its destination.
FIG. 2 and FIG. 3 are merely intended to illustrate a particular implementation of the Hamming Code with the SSFDC flash memory device, but are not intended to limit the scope of the discussion to this particular implementation.
As discussed above, the Hamming Code is a low power ECC. This limits the SSFDC flash memory device to applications not requiring an extreme level of data reliability. In addition, the SSFDC flash memory device is currently unsuited to handled the higher error rates of future flash memory cell technologies such as multi-bit flash memory cells. Even if the ECC on the SSFDC controller was changed to a high power ECC by the vendor, the potential market for such a product would be stymied by the lack of compatibility with the existing SSFDC controllers and products designed with the Hamming Code. The reason for this outcome lies in the interdependence between the ECC and the data reliability bits. Since each type of ECC generates vastly different data reliability bits, one type of ECC could not utilize the data reliability bits from a different type of ECC. Thus, the existing SSFDC controller would be unable to function properly with the modified SSFDC flash memory device, which is configured to operate with a high power ECC, while the modified SSFDC controller, which is configured to operate with a high power ECC, would be unable to function properly with the existing SSFDC flash memory device, thus undermining the objective of having multiple SSFDC vendors designing SSFDC controllers and products that are compatible with the SSFDC controllers and products of other SSFDC vendors.
In sum, there is no SSFDC flash memory device with a high power ECC that is compatible with existing standards.